1. Field of the Invention
The present invention relates to an object traversing over a structured memory formed by linked objects such as a data file system, a virtual memory space, and a database system utilized in computers.
Here, it is to be noted first that the term "object" used in this specification represents any collection of data, including not just data flies and programs but also various structures for operations to be temporarily utilized in a course of executing programs.
Also, a plurality of objects may be related with each other by links, and can be treated together as another object. In a case of regarding a plurality of objects together as a single object, each object constituting that single object may be referred as sub-objects.
2. Description of the Background Art
Conventionally known schemes for the object traversing over a plurality of linked objects include a scheme for sequentially tracing the links as in a hyper-text system, and a scheme for retrieving and presenting a relevant object group for a specified name as in a data file system for a computer. In addition, a scheme for limiting accessible objects depending on users and a scheme for temporarily changing an access right are also known.
Furthermore, it is also known to be possible to generally represent accessible objects and to read out a plurality of linked objects as a continuous data, by combining these schemes.
On the other hand, there is a recent attempt to combine these conventionally known schemes in which, at a time of constructing a large object by hierarchically combining a plurality of objects, an access right data is given to each sub-object and a procedure for making an access is changed by varying parameters, in order to represent a single combined object to appear as a number of different types of combined objects. This idea will now be described in further detail.
Here, an exemplary situation in which Mr. Takahashi is producing a directory file for members belonging to a certain group A will be considered as an illustrative example.
FIG. 1 shows a state in which the directory is produced by Mr. Takahashi as an object 121. In this FIG. 1, no file name is assigned to this directory file, but the file name may be assigned at this point if desired.
In this object 121 of FIG. 1, a field 1211 indicates an owner ID for an owner of this object 121, where a number "128" registered in this owner ID field 1211 represents Mr. Takahashi in this example as indicated in an entry 1311 on an ID table 131 shown in FIG. 2, while a field 1212 indicates a group ID for a group to which this object 121 belongs, where a number "320" registered in this group ID field 1212 represents the group A in this example as indicated in an entry 1312 on the ID table 131 shown in FIG. 2.
A field 1213 indicates the access rights assigned to the owner of this object 121, where RD, WR, and EX fields indicate the access rights for reading, writing, and execution, respectively. In this case, this object 121 is data and not program, so it cannot be executed and therefore the EX field has a value "0", while the owner of this object 121 certainly can read or write this object 121, so that the RD and WR fields have values "1".
A field 1214 indicates the access rights for this object 121 with respect to the members of the group A. In this case, this object 121 is certainly readable for the members of the group A as it is the data concerning this group A, so that the RD field has a value "1", but the WR field has a value "0" in order to protect the data of this object 121, while the EX field has a value "0" for the same reason as in the field 1213.
A field 1215 indicates the access rights for this object 121 with respect to those not belonging to the group A (non-members). In this case, the directory of the group is a secret matter which should not be disclosed to the non-members, so that the RD field has a value "0", while the WR and EX fields have the values "0" for the same reason as in the field 1214.
A field 1216 indicates the actual data of the directory. Here, instead of registering the actual data themselves in this field 1216, a pointer to the data or a block ID of a memory block storing the data may be registered, if desired.
Next, for the purpose of managing this directory file of FIG. 1, an object 141 shown in FIG. 3 for registering comments is produced by Mr. Takahashi.
In this object 141 of FIG. 3, a field 1411 indicates the owner ID for Mr. Takahashi in this example, and a field 1412 indicates a group ID for a group to which this object 141 belongs, where a number "320" registered for this group ID 1412 represents the group A in this example as indicated in an entry 1312 on the ID table 131 shown in FIG. 2.
A field 1413 indicates the access rights assigned to the owner of this object 141 similar to the field 1213 in FIG. 1. Fields 1414 and 1415 indicate the access rights for this object 141 with respect to the members and the non-members of the group A, respectively. In this case, the comments of this object 141 are not to be seen by the members as well as by the non-members of the group A, so that all the fields including the RD fields have values "0" in these fields 1414 and 1415. A field 1416 indicates the actual comments of this object 141.
Here, the assignment of the different access rights for different objects as in the case of the objects 121 and 141 of this example has been well known conventionally. The above noted recent attempt is further aimed at treating these plurality of objects as if they are just a one file by producing another object 151 shown in FIG. 4, which relates the object 121 with the object 141 and represents a single combined object for these objects 121 and 141.
In this object 151 of FIG. 4, a field 1511 indicates an object name which corresponds to a file name in a usual data file system and which is "group A directory" in this example. Fields 1512 and 1513 are the owner ID and the group ID similar to the fields 1411 and 1412 in FIG. 3.
A field 1514 indicates the access rights assigned to the owner of this object 151 similar to the field 1413 in FIG. 3 except that the WR field has a value "0" because there is no need to alter the structure of this object 151 itself even when the data and the comments for the directory are changed in future. Fields 1515 and 1516 indicate the access rights for this object 151 with respect to the members and the non-members of the group A, respectively. In this case, there is no reason to hide the fact that this file "group A directory" comprises the directory itself and the comments from anybody, so that the RD fields have values "1" in these fields 1515 and 1516.
A field 1517 is a bit indicating a presence or absence of sub-objects, which has a value "1" in this example as there are sub-objects, while a field 1518 indicates a number of sub-objects which is indicated as 2 in this example. Fields 1519 and 1520 indicate IDs of these two sub-objects, which are the IDs of the sub-objects 121 and 141, respectively, in this example.
By constructing these objects 121, 141, and 151 as described above, when Mr. Takahashi (ID: "128") reads the object 151 representing the file "group A directory", it is possible to learn that there are the sub-object 121 registering the directory itself and the sub-object 141 registering the comments, and Mr. Takahashi can make accesses to these sub-objects 121 and 141 as he has assigned the access rights for them. On the other hand, when any member of the group A (ID: "320") reads this object 151 named "group A directory", the content of the sub-object 121 registering the directory itself can be read, but the content of the sub-object 141 registering the comments cannot be read as there is no access right for this sub-object 141 assigned to the members of the group A.
Here, the access right for reading this object 151 is also assigned to the non-members as well, so that any non-member can also traverse over the sub-objects 121 and 141 by tracing the links from this object 151, but the access rights for reading these sub-objects 121 and 141 are not assigned to the non-members, so that the contents of these sub-objects 121 and 141 cannot be read by any non-member and therefore the secrecy of the directory can be maintained.
In this manner, it becomes possible to make all or a part of the objects to be accessible depending on the users. However, in the manner described above, it is impossible to realize more flexible representations in which the file "group A directory" appears as one file having comments for Mr. Takahashi, while this same file appears as a simple file without comments for the members of the group A.
Even when such more flexible representations are realizable somehow, the following problem still remains to be resolved.
Namely, suppose there is a program capable of printing the data of the directory by formatting it in an appropriate table format, which is programmed without knowing a presence of the comments attached to the directory. When this program is made to be available to the members of the group A and Mr. Takahashi executes this program, since Mr. Takahashi has the access rights for not only the directory itself but also for the comments which are not required by the program itself, the comments are going to be read out along with the directory itself such that this program may not operate properly because of the presence of the unexpected data. That is, even when Mr. Takahashi tries to read the "group A directory" file by using the access right assigned to the members of the group A, because of the stronger access rights assigned to Mr. Takahashi, the reading operation is going to be carried out for all the objects for which Mr. Takahashi has the access rights.
One of the widely used solutions to this type of a problematic situation has been the so called SUID (Set User Identification) scheme, disclosed in U.S. Pat. No. 4,135,240, which changes the access rights at a time of the execution of the program. Actually, this SUID scheme is intended for changing the rights assigned to the owner ID, so that it is not going to be applicable to above problem straightforwardly, but this SUID scheme can be modified in order to resolve the above problem as follows.
Namely, FIG. 5 shows an object 161 registering a usual program for directory formatting, while FIG. 6 shows a modified object 171 registering the similar program for directory formatting, where the identical fields of these objects 161 and 171 are given the identical reference numerals in FIGS. 5 and 6.
In this object 161 of FIG. 5, a SAID (Set Address ID) 1611 is unspecified, which implies that the program registered in this object 161 is going to operate in a normal manner. Fields 1613 and 1614 are the owner ID and the group ID similar to the fields 1411 and 1412 in FIG. 3. Fields 1615, 1616, and 1617 indicate the access rights for the owner, the member of the group A, and the non-members, respectively, where the execution right is limited to the owner and the member of the group A, while the reading and writing rights are limited only to the owner. A field 1618 registers the execution program itself which uses the object 151 of FIG. 4 as the data.
When this execution program 1618 is executed by any member of the group A other than Mr. Takahashi, the expected result can be obtained, but when this execution program 1618 is executed by Mr. Takahashi, the proper operation of the program may not be obtained as the unexpected data of the object 141 are also read out along with the expected data of the object 121.
In contrast, the modified object 171 of FIG. 6 differs from the object 161 of FIG. 5 in that a SAID 1612 has an ID "320" of the group A. As a result, when this object 171 is executed by Mr. Takahashi, the original access rights assigned to Mr. Takahashi as an executor of this program are abandoned, and only the rights assigned to the group A indicated by this ID "320" registered for the SAID 1612 become available to Mr. Takahashi.
This object 171 has the execution program 1619 in which the object 151 and the sub-objects 121 and 141 are going to be accessed by using the access rights assigned to the group A, so that the same data are going to be accessible regardless of who is executing this program, and the expected result can be obtained from this program 1619 by any member of the group A including Mr. Takahashi.
Thus, the above described conventional scheme can realize the object traversing using a special access right for relating the program with the data to be used by the program, but in this conventional scheme, the right to attach the SAID to the program remains uncertain. Namely, if the SAID can be attached to the program very easily, it is going to be possible to obtain the optional access rights as a result of using this program, such that the access rights attributed to each object become meaningless.
For this reason, it is necessary to manage the right to attach the SAID to the program by some other means, but there has been no effective solution to this problem conventionally, and this right to attach the SAID to the program has been assigned only to the privileged user called root.
This assignment of the right to attach the SAID to the program only to the privileged user is a severe constraint because the right to set up the access rights for the object should be given to the owner of that object in principle. Moreover, in this assignment, the access rights which should have been attributed to the objects themselves are going to be controlled only by the setting of the program which is unrelated to the objects themselves, so that it is a highly inconvenient constraint which cannot really realize the protection mechanism expected for the objects.
As described, in the conventionally available schemes, only the access rights are available for conditioning the object traversing, so that it has been difficult to change the manner of object traversing according to different manners of utilizing the objects, and it has been impossible to specify the appropriate manner of object traversing in each object itself.
Furthermore, even in a case of making an access to a group of objects as a whole by regarding them as a single file, as long as only the access rights are used, it has been impossible to specify what manners of accesses are actually going to be made in the objects themselves.